home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
011
/
dosevrn.dqc
/
dos-evrn.doc
Wrap
Text File
|
1985-07-14
|
4KB
|
102 lines
From rss Fri Jun 21 19:33 CDT 1985
How to fix the environment space in DOS.
By Roger Schlafly, Borland International
Memory allocation for environment space was badly botched by
Microsoft. DOS only allocates 127 bytes initially, and this
cannot be increased after loading a resident program like PRINT
or Sidekick. DOS will allocate more memory if no program is
resident and the set command was typed at the keyboard, but
running set commands from batch files is totally unreliable.
The following patch increases the environment space to 2K on
PC-DOS 3.1:
debug COMMAND.COM
e cs:D11
80
w
q
How the patch works.
At boot time, COMMAND.COM allocates memory for the environment
space by DOS function call 48H. The argument for this function is
the number of paragraphs to be allocated, and is in register BX.
A paragraph is 16 bytes. COMMAND.COM allocates 160 bytes when it
creates the environment space, so it calls DOS function 48H with
0AH in register BX. In earlier versions of DOS, including PC-DOS
2.00, the code in COMMAND.COM which set the environment space
was:
MOV BX,0AH
MOV AH,48H
INT 21H
These versions of DOS can be patched by searching COMMAND.COM for
these instructions:
debug COMMAND.COM
s cs:0 6000 BB 0A 00 B4 48 CD 21
There should be just one occurrence. Changing the 0A to 80 (hex)
will increase the environment space to about 2K the next time you
reboot.
Later versions of DOS, including PC-DOS 3.10, store the number of
paragraphs to allocate to the environment in a memory location in
the data segment. The relevant code is:
cs:0D0D C7063A138000 MOV Word Ptr [133A],000A
cs:0FFF 8B1E3A13 MOV BX,[133A]
cs:1003 B448 MOV AH,48
cs:1005 CD21 INT 21
Note that the memory location [133A] is valid for PC-DOS 3.10
only. If you have another version of DOS, or a non-IBM version of
MS-DOS 3.10, the memory location may be different. The following
procedure may be used to find the correct byte to patch.
1. Load COMMAND.COM into DEBUG. (Preferably, not your only copy.)
2. Search for all 48H DOS functions by searching for the hex
string B4 48 CD 21. There are about ten.
3. Unassemble the surrounding code to see what gets loaded into
BX. If BX is being set to FFFFH or any constant other than 0AH,
or is based on a computation, then you are looking at the wrong
function call.
4. There should be just one function call left. If 0AH is being
copied directly into BX, then that is the byte to patch. If a
memory location is being copied into BX, then search for moves
into that memory location. For example, if the memory location is
1234, then search for C7 06 34 12 0A 00 since those are the
opcodes for MOV Word Ptr [1234],000AH. This 0AH can be replaced
by a larger number.
Final remarks.
1. Needless to say, modifying the wrong byte in COMMAND.COM can
have undesirable consequences. If you are not sure that you
patched it correctly and you notice DOS acting peculiarly,
restore the old copy of COMMAND.COM.
2. A company called Soft Shell Technology used to sell a very
nice program which could expand the environment space and fix a
number of other botches such as the inability of Wordstar to run
from other than the default directory. Sadly, however, they went
out of business and their program only worked with PC-DOS 2.00.
3. According to Soft Shell Technology, the number to replace 0AH
in COMMAND.COM should not be between 2DH and 45H.